feat(web): support optional custom color palettes - #107

Motivation

Closes #106.

Users may have a familiar color palette in their editor or terminal and prefer a similar reading experience in the web client. This proposes an opt-in way to bring those colors to the interface and Conversation History, while leaving the existing Auto / Light / Dark defaults unchanged.

Changes

• Add a Custom appearance option and a collapsible JSON palette editor in Settings, with Apply and Reset controls.
• Accept a light or dark color scheme and exactly ten allowlisted semantic #RRGGBB colors. Limit input to 4096 characters and validate the specified text/accent contrast pairs at 4.5:1 before applying.
• Save preferences in this browser and restore them before first paint. Switching back to a built-in appearance removes custom overrides without discarding the saved palette.
• Handle invalid saved palettes and unavailable browser storage safely; show validation errors or a tab-only persistence notice. Include radio-group keyboard navigation and live status feedback.
• Document the format and scope, add regression tests, and make asset checks work with cache-versioned URLs.

This is limited to the web interface and Conversation History. It does not change live-terminal ANSI/truecolor output, accept arbitrary CSS or remote theme URLs, or add theme dependencies or a preset catalog. The example palettes below are user configurations, not new built-in themes.

Visual examples

Browser-rendered previews using synthetic English fixtures, not original phone screenshots. The history comparisons use identical content and layout in a 390 × 844 CSS-pixel viewport. No private conversations, endpoints, or device metadata are included.

Built-in Light — unchanged	Custom warm light example	Custom cool dark example

Settings: Custom palette editor

Verification

• sh tests/run.sh: 23 passed, 0 failed, including 303 real-browser web tests with no browser-test skips.
• Added 19 custom-theme browser regression tests covering validation, contrast, persistence/pre-paint restore, built-in fallback/reset, unavailable storage, keyboard navigation, mobile widths, History rendering, unchanged terminal colors, and no relay writes.
• node --check for every web/js/*.js, sh -n tests/run.sh, and git diff --check passed.
• The requester separately reviewed the appearance on a phone and reported no visual issues. This is an appearance check, not a claim of comprehensive device or accessibility coverage.
• The web client has no build step. macOS/Swift-only checks were skipped because this validation host is Linux without swiftc.

Feedback on the scope or palette format would be very welcome; I am happy to adjust this to fit the project's preferred approach.